2026 W08 주간회고
2026-02-09 주간보고 Recap
[2026-02-09 주간 보고]
- 지난주 업무 (업무명/결과)
- Master Plan 포함한 prod v1.12.0 release 릴리즈 및 배포 완료
- 일정공유 > 리크루팅 태스크를 신설
- 장기대관 예약 전 "충돌 사전검사(Precheck)"
- 지난주 이슈 (이슈발생일 / 이슈명 / 결과)
- 현재 업무 (업무명/목표/마감일)
- 장기대관 예약 전 "충돌 사전검사(Precheck)" / PR 메시지 작성중, 금일 내로 dev 배포
- 리크루팅 코어기능중 주최자 자격취득 시나리오를 감싸는 공통 인터페이스 정의
2026-02-19 주간보고 Recap
[2026-02-19 주간 보고]
- 지난주 업무 (업무명/결과)
- 마스터플랜을 비롯한 전반적인 플랜 리팩터링에 대한 QA 진행
- 현재 업무 (업무명/목표/마감일)
- 리크루팅기능 코어구조
- 주최자 자격검증 및 스태프의 프로필관리 (24hr) / UNTIL 2/25
- 리크루팅 개설 (20hr)
- 리크루팅 신청 및 결제 및 환불 (24hr)
- 리크루팅 확정 및 진행 (16hr)
- 리크루팅 정산 (?hr)
- 리크루팅기능 중 원데이클래스기능 확장 ... 코어구조와 함께
- 코치 공개프로필 작성 / UNTIL 2/25
- 원데이클래스 개설
- 원데이클래스 신청 및 결제 및 환불
- 원데이클래스 확정 및 진행
- 리크루팅기능 코어구조
W7,8 주간회고
이번 주 잘한 일
UCOP.spec 기능을 구현하던 중 디자인 초안과 충돌하는 부분 세가지를 발견하여 공유하였고, 빠르게 디자인 수정사항 요청 + 도메인 구조 변경으로 이어질 수 있었다. 물론 팀 전체 + 대표님과의 의견공유가 필요한 상황. 월요일 해당 안건 가지고 회의를 진행할 예정. 클릭업 디자인 요청사항 링크
- 주최자 등록 플로우 타이밍에 따른 세가지 Artifact 타입
- 정산프로필은 모든 Recruiting Type마다 동일한 프로필 레퍼런스를 공유
- 회원승급시 라켓타임 유저여야 하는가? → 디자인 초안이 변경되어야 함.
대표님의 "클래스 생성시 코치는 임의의 동의필드를 추가하여야 함" 이라는 요구사항을 구체화하여 "주최자는 임의의 동의필드를 추가하여 "홍보영상 촬영동의"와 같은 신청자들이 사전에 인지할 수 있어야 한다."는 내용을 바로 recruiting.core.spec에 추가하였다.
이번 주 아쉬운 일
백엔드 팀원의 "장기대관 대리예약" 기능의 알림발송 타이밍에 대한 정책이 공유/공지가 되지 않아 소비자 불만사항 발생. 아래와 같은 정책문서를 클릭업 POLICIES 에 추가해놓으라고 전달함. 그런데 이게 개발자는 KST로 바라보고 서버는 UTC로 바라보고 있는지라 dayjs 하루의 시작과 끝이 09시 또는 15시를 경계로 날짜가 달라지는 문제를 해결하지는 못해 정책문서 자체가 이해하기 어려운 한계가 존재함. 추후 이 문제를 대대적으로 손 볼 필요가 있음.
- 결제마감:
- 예약시간이 09시 이전일 경우: 예약일 08:59
- 예약시간이 09시 이후일 경우: 예약일 다음날 08:59
- 결제마감임박 알림:
- 결제 마감 - 48시간
- 다음 결제마감:
- 예약시간이 09시 이전일 경우: 첫번째 가예약일의 08:59
- 예약시간이 09시 이후일 경우: 첫번째 가예약일 다음날 08:59
- 다음 연장결제 알림:
- 다음 결제마감 - 24 * 8시간
- 다음 연장결제마감임박 알림:
- 다음 결제마감 - 48시간
인지부하를 일으키는 아직 해결되지 않은 과제들
Project (이번 달 안에 끝내야 하는 것)
Area (지속 운영 체계)
- 2026-01-29 aws cloud watch + log setting 언제 또 배포한 서버가 CPU 7,80%를 찍고 터질지 모른다. 적어도 error, warning 로그는 추적하고 있어야 한다. 그리고 메모리 사용량!
Resource (리서치 필요 혹은 위임)
- coach-plan.spec forwarded to teammate
W9 목표
WHY
문서를 많이, 그리고 자주 작성하고도 애자일할 수 있음을 보여주자.
WHAT
빅뱅 업데이트보다 유스케이스 Set 위주로 dev로 주기적으로 배포하여 클라이언트 개발이 지체되는 현상을 방지한다.
빠른 피드백 루프 문화를 형성한다.
- 배포 단위는 작게
- 정책은 확정된 것만
- Core Interface는 변하지 않게
HOW
예정된 2/25 수요일까지 리크루팅 기능 중 UCOP.spec 유스케이스 Set에 대한 구현물부터 dev 환경으로 배포한다. 이 작업물은 RacketimeException을 제외한 단 한 줄도 기존 코드를 수정하지 않기 때문에 prod 환경으로 배포해도 안전하다.
Feedback
-
리크루팅 기능이 성공했는지 판단할 단 하나의 지표는 무엇인가?
- EventStore에
Operator*,Recruiting*같은 리크루팅 관련 이벤트가 주 100건 이상 쌓인다 - Recruiting 관련 Exception 발생률 < 1%
- EventStore에
-
다음 주에 네가 의도적으로 넘길 결정 하나는 무엇인가?
- KST/UTC/Timezone 문제
-
Timezone 문제는 Project로 올릴 것인가, Area로 유지할 것인가?
- Area로 내린다. 그리고 ClickUp 백엔드 리팩토링 요구사항 리스트에 startOfDay, endOfDay 관련 불일치 문제 해소 태스크로 뽑아만 놓았다.
생각해볼 문제
-
Recruiting 이벤트 100건은
자연 발생인가? 아니면 내부 테스트인가? -
이벤트가 쌓이는데
운영자가 이해 못 하는 로그는 없는가? -
EventStore가 진짜
“의사결정 기록소”로 쓰이고 있는가?
아니면 단순 추적 로그인가?
지금은 속도가 아니라 관찰이 중요한 구간이다.
- 이벤트 패턴
- 알림 타이밍
- 정책 오해
- 팀 내 발화 패턴
이걸 기록해라.